Save response form documents as draft assets until publication v2 [WHIT-3750] - #11764

Consultation and call for evidence response documents were always uploaded as live assets in Asset Manager, even while the owning edition was still a draft or access-limited. This commit switches them to use the same draft/access-limited storage flow that File attachments use, so they're gated by the parent edition's access controls until it is published.

Note: `AssetData` is auto-discovered by a shared test helper
(`for_each_asset_data_type`) in `test/attachment_test_helper.rb` and it previously scanned by module inclusion. Since Consultation/CallForEvidence response form models now include `AssetData` too, that scan was changed to an explicit `%w[AttachmentData ImageData]` list to avoid sweeping response form data into shared tests built for generic editions.

Response form data models have no `replaced_by_id` column / Replaceable concern (unlike AttachmentData/ImageData), so AssetManagerAttachmentMetadataJob's `replaced_by` lookup would raise an error for them whenever their parent documents are updated.
I've now added a guard to the lookup so that it skips the replacement operations for such models.

This flips response document assets from draft to live once the owning
Consultation/CallForEvidence is published. It mirrors how
AttachmentAssetPublisher already does this for file attachments and
images.

There's a trade-off though: this couples the otherwise edition-agnostic publisher to Consultation/CallForEvidence's specific association chains. Probably okay, pending when we migrate these document types to standard edition.  The same trade-off already exists in `EditionAuthBypassAssetPropagator` which branches on the same two edition types for the same reason, so this follows the existing approach.

…dits

Previously, changing a consultation/call for evidence's access-limiting after its response document was uploaded never propagated to the asset in Asset Manager since `AssetManagerAttachmentMetadataJob` only re-ran at upload time. This is because `ServiceListeners::AttachmentUpdater`
(which re-syncs on every edition save) had no branch for response form
data, only Attachment/Image. I've now added that branch and also included some explicit tests for that behaviour.

…eleted

DraftAttachmentAssetDiscarder was built to only handle Attachment/Image, so a draft Consultation/CallForEvidence that is deleted before ever being published would leave its response document as an orphaned draft asset in Asset Manager.

AssetData's `needs_discarding?` (attachments.size == 1) gives us an ideal answer for response form data. i.e The attachments method on a Response Form Data always returns exactly one item (the response form, or Attachment::Null as a fallback). Therefore, it's always safe to discard; unlike in AttachmentData/ImageData, where size > 1 would mean the same data is still referenced by another (possibly) live attachment.

Storage::PreviewableStorage was only ever used by ImageUploader and ResponseDocumentUploader. Both have since moved to Storage::AttachmentStorage (images in #11667, response documents in this PR), so nothing references PreviewableStorage anymore.